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Abstract 


The  Midcourse  Space  Experiment  (MSX)  is  a  Strategic  Defense  Initiative  Organization  pro¬ 
gram  whose  primary  purpose  is  to  conduct  tracking  event  experiments  of  targets/phenomena 
in  midcourse. 

In  this  report  we  describe  the  portion  of  the  MSX  spacecraft  tracking  processor  software 
that  we  have  selected  for  verification  in  SDVS.  We  then  enumerate  the  Ada  constructs 
appearing  in  this  part  of  the  software  that  are  not  currently  handled  by  the  SDVS  Ada 
translator,  but  which  we  intend  to  implement.  We  also  mention  some  of  the  problems  that 
we  expect  to  encounter  in  the  course  of  the  project. 
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1  Introduction 


The  purpose  of  this  report  is  to  document  the  first  phase  of  a  joint  project  between  The 
Aerospace  Corporation  (Aerospace)  and  the  Johns  Hopkins  University  Apphed  Physics 
Laboratory  (JHU/APL)  to  verify  a  portion  of  the  Midcourse  Space  Experiment  (MSX) 
spacecraft  tracking  processor  software.  Primarily,  the  purpose  of  the  project  is  to  evaluate 
the  apphcability  of  the  State  Delta  Verification  System  (SDVS)  to  the  verification  of  apph- 
cation  programs  written  in  high-level  languages.  A  byproduct  wOl  be  the  knowledge  gained 
by  JHU /APL  of  the  value  of  applying  formal  methods  in  DoD  programs. 

The  first  phase  of  the  project  consisted  of 

(i)  selecting  and  analyzing  a  portion  of  the  MSX  Ada  code  to  be  verified, 

(ii)  examining  the  documentation  pertaining  to  that  portion,  and 

(iii)  deUneating  the  Ada  constructs  that  appear  in  that  portion  but  that  the  SDVS  Ada 
translator  does  not  currently  handle.  (For  a  description  of  SDVS  see  [1],  [2],  and  [3].) 

MSX  is  a  near-term  Strategic  Defense  Initiative  Organization  program  whose  primary  pur¬ 
pose  is  to  conduct  tracking  event  experiments  of  targets/phenomena  in  midcourse.  In  a 
tracking  event,  the  main  spacecraft  systems  are  the  command  processor,  the  attitude  pro¬ 
cessor,  the  tracking  processor,  the  sensors,  and  the  data-handhng  system  (telemetry).  The 
command  processor  receives,  buffers,  and  relays  commands  for  a  network  consisting  of  the 
ground  and  the  spacecraft  subsystems.  The  attitude  processor  interfaces  to  the  attitude 
sensors  and  controllers.  Its  primary  function  is  to  determine  and  control  the  spacecraft 
attitude.  The  fundamental  function  of  the  tracking  processor  is  to  generate  sufficient  infor¬ 
mation  for  the  attitude  processor  to  point  the  spacecraft  at  the  desired  target,  location,  or 
direction.  The  tracking  processor  is  designed  around  a  MIL-STD-1750A  (1750A)  micropro¬ 
cessor  with  2K  of  ROM,  512K  of  RAM,  and  256K  of  EEPROM. 

When  the  spacecraft  is  not  involved  in  a  tracking  event,  the  tracking  processor  is  turned 
off  to  conserve  power.  During  these  periods,  the  direction  of  the  spacecraft  is  controlled 
autonomously  by  the  attitude  processor  and  is  in  “parked  mode.”  Before  a  tracking  event  is 
to  take  place,  the  tracking  processor  is  turned  on  by  a  real-time  or  delayed  command.  Then 
the  ROM  is  used  for  power  up,  the  software  and  data  for  the  tracking  event  are  loaded  into 
storage  from  EEPROM  to  RAM,  and  the  event  begins. 

During  the  current  event  and  for  the  preparation  of  the  next  tracking  event,  commands  are 
generally  upHnked  from  the  ground  to  the  command  processor  and  relayed  to  the  tracking 
processor  via  a  serial  port.  These  serial  digital  commands  are  combined  by  the  tracking 
processor  to  form  apphcation-level  messages,  which  are  then  stored  in  RAM,  EEPROM, 
or  both.  There  are  eleven  types  of  apphcation-level  messages.  One  of  these,  the  data- 
structure  memory-load  apphcation  message  (data-structure  message,  for  short),  can  modify 
up  to  about  120  tracking  parameters  used  in  a  tracking  event.  The  number  of  commands 
required  to  form  a  data-structure  message  is  a  function  of  the  type  of  tracking  parameter 
the  data-structure  message  modifies. 
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The  target  software  we  have  selected  for  verification  is  that  part  of  the  tracking  processor 
software  that  processes  serial  digital  commands  from  the  command  processor  into  data- 
structure  messages  and  then  stores  the  messages  into  RAM,  EEPROM,  or  into  both.  Onr 
knowledge  of  the  MSX  program  in  general,  and  of  the  specifications  and  the  software  for 
the  tracking  processor  in  particular,  was  culled  from  discussions  with  Richard  Waddell  and 
Shane  Hutton  of  JHU/APL  and  from  the  following  documents; 

•  R.  L.  Waddell,  “MSX  Tracking  Processor  Software  Requirements  Specification,”  SlA- 
104-89  JHU/APL,  1989; 

•  R.  L.  WaddeU  and  S.  Hutton,  “Midcourse  Space  Experiment  (MSX)  Tracking  Proces¬ 
sor  Software  Functional  Design,”  SlA-031-90  JHU/APL,  1990; 

•  S.  F.  Hutton,  “Tracking  Processor  /  Command  Processor  Interface  Design  Specifica¬ 
tion  (Version  2),”  SlA-136-91  JHU/APL,  1991; 

•  G.  Heyler,  S.  Hutton,  and  R.  WaddeU,  “Midcourse  Space  Experiment  (MSX)  Tracking 
Processor  Software  Detailed  Design  Document,”  SlA-084-91  JHU/APL,  1991; 

•  a  portion  of  the  MSX  software. 

The  specification  for  the  target  software  wiU  be  extracted  primarily  from  the  third  of  the 
documents  listed  above:  this  document  contains  the  specifications  for  aU  of  the  application 
messages  and  data  structures  loaded  from  the  command  processor  to  the  tracking  processor. 

In  Section  2  of  this  report  we  give  a  brief  outline  and  description  of  the  target  software; 
some  of  the  code  wUl  probably  not  be  translated  by  the  SDVS  Ada  translator,  for  reasons 
we  wUl  make  clear.  We  intend  to  characterize  these  parts  of  the  code  by  either  state  deltas 
or  by  a  form  of  the  SDVS  Ada  offline  characterization  facility  [4]. 

Section  3  is  an  enumeration  of  the  Ada  constructs  [5]  in  the  target  software  that  the  SDVS 
Ada  translator  does  not  currently  handle.  For  each  such  construct,  we  wiU  discuss  our 
proposed  solution.  The  possible  solutions  are  as  foUows: 

•  implement  the  construct  in  SDVS 

•  delete^  it  from  the  MSX  example 

•  replace  it  by  functionaUy  equivalent  Ada  code 

•  replace  it  by  nonequivalent  Ada  code  (tasking) 

•  encapsulate  procedure  and  function  bodies  in  which  it  occurs  by  means  of  the  SDVS 
ofiiine  characterization  facility 

Finally,  in  the  last  section,  we  discuss  our  current  work  on  the  project  and  our  plans  for  its 
near  future. 

^AU  deletions  and  replacements  wiU  be  made  in  the  software  that  wiU  be  translated  by  the  SDVS  Ada 
translator  and  wiU  not  affect  the  actual  software  for  the  MSX  program. 
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2  A  Functional  Overview  of  the  Code 


We  focus  in  this  section  on  that  pajt  of  the  tracking  processor  software  that  receives  and 
buffers  up  to  70  commands  from  the  command  processor,  builds  the  appropriate  application 
messages  from  a  list  of  commands,  stores  these  messages  in  a  circular  message  queue,  and 
then  processes  the  messages  according  to  their  specifications.  During  the  construction  of  the 
messages,  a  number  of  tests  are  performed  on  the  integrity  of  the  commands  and  messages, 
and  the  status  of  the  tracking  processor  is  reported  to  telemetry. 

Our  intent  is  to  verify  that  the  data-structure  messages  are  built  according  to  their  specifi¬ 
cation.  To  illustrate  the  type  of  serial  digital  commands  required  to  build  a  data-structure 
message  and  to  get  an  overview  of  its  construction,  consider  the  Beacon  Alignment  First 
Object  data-structure  message.  This  message  encodes  a  3x3  real  matrix  that  is  required 
to  be  stored  in  both  EEPROM  and  RAM.  The  matrix  has  9  real  number  entries,  and  each 
real  number  requires  4  bytes.  Therefore,  the  matrix  requires  a  total  of  36  bytes  of  data. 

A  byte  is  8  bits  long;  a  word  is  16  bits  long;  and  a  command  consists  of  two  words.  In 
the  Ada  code,  bytes  and  words  are  represented  by  integers  constrained  to  specific  ranges. 
Although  bytes  (words)  have  an  integer  parent  type,  they  encode  sequences  of  O’s  and  I’s 
that  are  8  (16)  bits  long.  For  example,  if  the  byte  B  =  7,  B  encodes  (i.e.,  contains)  the  bit 
sequence  <  00000111  >. 

Fourteen  commands  are  needed  for  the  construction  of  the  Beacon  Alignment  First  Object 
data  structure  (see  Table  1).  The  first  bit  of  the  first  byte  of  each  command  is  the  parity 
bit  for  the  entire  command.  The  other  bits  serve  the  functions  we  outline  below. 

(i)  Command  1: 

•  The  last  seven  bits  of  the  first  byte  encode  the  op-code  of  the  command.  For  a 
command  that  begins  a  data  structure  load  message,  the  op-code  is  1. 

•  The  second  byte  encodes  the  storage  information;  EEPROM,  RAM,  or  both. 
For  the  Beacon  Alignment  First  Object  data  structure,  which  according  to  the 
specifications  must  be  stored  in  both  EEPROM  and  RAM,  this  byte  must  be 
equal  to  2. 

•  The  third  byte  contains  the  identification  code,  ID,  of  the  data  structure.  For 
the  Beacon  First  Alignment  Object,  this  code  is  1. 

•  The  fourth  byte  is  the  first  byte  of  data,  di,  for  the  matrix. 

(ii)  Command  n  where  1  <  n  <  12: 

•  The  last  seven  bits  of  the  first  byte  encode  the  op-code,  which  is  8,  for  a  data- 
structure  load  continuation  command. 

•  The  other  three  bytes  are  the  fiual  bytes  of  data  for  the  matrix:  d^n-A,  d^n-s, 
and  d^n—2- 

(iii)  Command  13: 

•  The  last  seven  bits  of  the  first  byte  encode  the  continuation  op-code  8. 

•  The  next  two  bytes  are  the  next  bytes  of  data  for  the  matrix:  dss  and  dze- 
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•  The  fourth  byte  is  the  first  byte  of  the  2-byte  checksum. 

(iv)  Command  14: 

•  The  last  seven  bits  of  the  first  byte  encode  the  continuation  op-code  8. 

•  The  second  byte  is  the  second  byte  of  the  checksum. 

•  The  third  and  fourth  bytes  are  spares. 


Table  1:  Beacon  Alignment  First  Object 


Command  1 
Command  2 

Command  n 

Command  13 
Command  14 


Byte  1 

Byte  2 

Byte  3 

Byte  4 

p2 

1 

2 

1 

di 

P 

8 

d2 

dz 

d^ 

P 

8 

^3n— 4 

dzn-Z 

dzn-2 

P 

8 

dz5 

dze 

checksum 

P 

8 

checksum 

spare 

spare 

®  P  is  the  parity  bit. 


2.1  Process  Commands/Data  from  Command  System 

We  have  examined  eighteen  library  units  that  fall  either  in  the  area  or  in  the  periphery  of 
our  target  software.  Below,  we  group  these  units  according  to  their  function,  list  some  of 
their  more  important  subunits,  and  discuss  their  role,  if  any,  in  our  target  software.  Units: 
ARRAY_OF_BLOCKS,  SERIAL_DIG_COMMANDS,  and  APPAISGS 

(i)  ARRAY_OF_BLOCKS 

ARRAY.OFJBLOCKS  is  used  only  for  long-memory  loads,  which  are  not  in  the  category 
of  application  messages  we  have  selected  for  verification;  we  will  thus  not  consider  this 
package,  but  wiU  describe  the  remaining  two  in  some  detail. 

(u)  SERIAL-DIG-COMMANDS 

This  Ada  package  contains  the  procedures  CMDJN-HANDLER  and  RET_CMD_BTJF_AND.STATUS. 

•  CMDJN-HANDLER  is  a  procedure  that  services  interrupts  that  occur  when  the 
command  processor  is  ready  to  transmit  a  command  to  the  tracking  processor. 

It  obtains  the  command  in  the  format  of  an  array  of  4  words  (see  Table  2), 
processes  the  array  as  a  packed  record  of  4  byte  fields  (see  Table  2),  and  then 
stores  this  command/record  in  a  buffer  that  can  buffer  up  to  70  commands  (see 
Table  3).  It  stores  the  status  of  each  command  in  a  separate  status  buffer  and 
also  performs  parity  checks. 
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Table  2:  Command  Formats 


Command  Obtained:  Array  of  4  Words 


00000000 

First  Byte 

00000000 

Second  Byte 

00000000 

Third  Byte 

00000000 

Fourth  Byte 

Command  Processed:  Packed  Record 


First  Byte 

Second  Byte 

Third  Byte 

Fourth  Byte 

Table  3:  CmdJBuf 


Command  1 
Command  2 
Command  3 


Command  N 


First  Byte 

Second  Byte 

Third  Byte 

Fourth  Byte 

First  Byte 

Second  Byte 

Third  Byte 

Fourth  Byte 

First  Byte 

Second  Byte 

Third  Byte 

Fourth  Byte 

First  Byte 

Second  Byte 

Third  Byte 

Fourth  Byte 

•  The  procedure  RET.CMDJBUF-ANDJSTATUS  is  called  within  an  infinite  loop  by  a 
task  in  APP_MSGS  to  retrieve  the  command  and  command-status  buffers  created 
by  CMDJN_HANDLER. 

(iii)  APPJ\4SGS 

This  Ada  package  contains  the  tasks  BUILD,  PROCESSJMSG,  and  MANAGE_MSG_RETRIEVAL, 
and  the  two  procedures  INITIATE_BUILD  and  CONTINUE_BUILD. 

•  BUILD  calls  SERIALJDIG.COMMANDS.RET.CMD.COUNT  repeatedly  to  see  if  there 
are  any  commands  in  the  command  buffer  to  be  processed  into  messages.  If 
there  are,  it  then  calls  SERIALJDIG_COMMANDS.RET.CMDJBUF_AND.BTATUS  to 
obtain  the  command  buffer.  If  the  op-code  of  the  first  command  in  the  command 
buffer  indicates  that  this  command  is  the  beginning  of  an  application  message, 
BUILD  calls  INITIATE_BUILD  to  start  the  build  of  the  message.  Otherwise,  it 
calls  CONTINUE-BUILD  to  continue  the  build  of  the  application  message  currently 
being  processed.  CONTINUE_BUILD  may  be  called  repeatedly  until  the  message  is 
complete  (see  Tables  4  and  5).  Note  that  the  message  is  constructed  in  stages;  it 
is  quite  possible  BUILD  will  retrieve  more  than  one  command  buffer  to  construct 
a  message.  When  a  message  has  been  successfully  constructed,  CONTINUE_BUILD 
places  the  message  in  a  circular  message  queue  (see  Table  5)  that  may  hold  up 
to  30  messages  and  control  returns  to  BUILD.  If  BUILD  has  constructed  at  least 
one  message  from  the  most  recently  retrieved  buffer  of  commands,  it  waits  for  a 
rendezvous  with  the  task  MANAGE_MSG_RETRIEVAL. 
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•  If  the  message  queue  is  not  empty,  PROCESS_MSG  will  rendezvous  with  the  task 
MANAGE_MSG_RETRIEVAL  to  retrieve  the  message  at  the  head  of  the  queue.  If 
the  message  is  a  data  structure  load,  it  writes  it  in  EEPROM  or  RAM  or  in  both 
(depending  on  the  information  contained  in  the  message). 

•  The  task  MANAGE_MSG_RETRIEVAL  coordinates  the  execution  of  the  other  two 
tasks  by  a  guarded  select  statement.  It  shares  a  message-counter  variable  with 
CONTINUE_BUILD;  CONTINtJE_BUILD  increments  this  variable  when  it  stores  a 
message  in  the  message  queue  and  MANAGE-MSG-RETRIEVAL  decrements  it  upon 
its  rendezvous  with  PROCESS_MSG.  This  message-counter  variable  must  be  posi¬ 
tive  for  a  rendezvous  to  take  place  between  MANAGE_MSG_RETRIEVAL  and  PRO- 
CESS-MSG. 


After  Continue_BuUd  1st  Time 


After  Initiate-BuUd 

1 

0 

0 

1 

0 

0 

0 

OP 

2 

0 

OP 

EEPROM/RAM 

ID 

3 

ID 

di 

dz 

4 

di 

To  Be  Continued 

dz 

d^ 

To  Be  Continued 

After  Continue-Build  3rd  Time 

After  ContinueJBuild  2nd  Time 

1 

0 

0 

1 

0 

0 

2 

0 

OP 

2 

0 

OP 

3 

EEPROM/RAM 

ID 

3 

EEPROM/RAM 

ID 

di 

dz 

4 

di 

d2 

dz 

5 

ds 

d4 

dz 

de 

6 

ds 

de 

7 

dr 

dz 

7 

dr 

To  Be  Continued 

8 

dg 

dio 

9 

To  Be  Continued 

Table  4:  Piecewise  Building  of  Apphcation  Message 


2.2  Ada  Packages  that  Depend  on  the  Tartan  Compiler 

Units:  INTRINSICS,  INTRINSIC-FUNCTIONS,  and  UNCHECKED-CONVERSION 

The  INTRINSICS  package  is  a  part  of  the  Tartan-^  library  of  packages  and  contains  generic 
functions  and  procedures  that  are  system  dependent.  They  are  generally  used  to  do  bit 

®The  MSX  Tracking  Processor  Ada  software  will  be  compiled  by  a  Tartan  ([6])  compiler. 
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Completed  Message 

1 
2 

3 

4 


n 


20 

21 


Table  5:  Completion  and  Storage  of  Message 

manipulations,  such  as  the  marking  of  bits.  The  INTRINSICJFUNCTIONS  package  contains 
instantiations  of  the  generic  functions  and  procedures  in  the  INTBJNSICS  package.  The 
UNCHECKED.CON VERSION  generic  function  is  used  to  convert  between  different  data  types. 
Since  these  packages  are  used  extensively  in  the  target  software,  and  since  their  implemen¬ 
tation  is  compiler-dependent,  we  will  encapsulate  the  functions  and  procedures  that  they 
contain  by  using  the  SDVS  Ada  offline  characterization  utility. 


0 

0 

0 

OP 

ID 

di 

d2 

da 

HSSBfSi 

das 

dae 

checksum 

checksum 

In  App-Msg-Q 


0 

OP 

EEPROM/RAM 

ID 

di 

d2 

da 

d^. 

■ESSSBIHi 

IBSflSSSIII 

das 

dae 

checksum 

checksum 

2.3  Type  Definitions 

Units:  GLOBAL.TYPES  and  CMDS.TYPES 

As  their  names  indicate,  these  two  packages  contain  the  type  definitions  (such  as  WORD 
and  BYTE,  which  are  derived  integer  types)  common  to  most  of  the  code. 


2.4  Output  Telemetry 

Units:  TM,  TMJ3ATA,  and  PRIME_SCIENCE_DATA 

All  three  of  these  Ada  packages  appear  only  peripherally  in  our  target  software:  calls 
to  subprograms  or  rendezvous  with  tasks  of  these  packages  are  made  only  to  report  house¬ 
keeping  data  for  telemetry  (such  as  system  errors).  For  this  reason,  it  should  be  relatively 
easy  to  bypass  them  in  the  translation  of  the  target  software. 


2.5  Tracking  Parameters 

Units:  TRKING_DATA^TRUC  and  TRKING_PARAMS 
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The  TRKING-DATA^TRUC  package  in  this  group  is  only  used  in  the  target  software  to 
determine  the  number  of  words  needed  to  buUd  each  type  of  data-structure  application 
message;  therefore,  the  package  wiU  be  translated  into  SDVS  (or  at  least  the  portions  of  the 
package  that  are  needed).  The  second  package  in  this  group,  TRKING_PARAMS,  is  only  used 
by  the  task  PROCESS-MSG  of  our  target  software  to  store  a  tracking-structure  application 
message  by  an  extended  rendezvous  with  the  task  MANAGE  of  TRKING_PARAMS  for  those 
data  structures  to  be  stored  in  RAM  (or  in  both  RAM  and  EEPROM).  The  rendezvous 
only  passes  the  data  structure  to  be  stored  and  could  be  easily  specified  in  SDVS  by  a  form 
of  oflBbne  characterization. 


2.6  Control  Mode/State 
Unit:  MODE_STATE 

The  Ada  package  MODE^TATE  is  only  used  in  our  target  software  to  obtain  information 
about  the  status  of  the  mode  state,  e.g.,  power_up,  init_EEPROM_write,  tracking.  It  should 
be  easy  to  translate  the  results  of  such  calls  by  offline  characterization. 


2.7  Track  Targets 

Units:  POINTINGJNFO.OUT  and  TRK.TARGETSJSRJPKG 

TRK.TARGETSJSR-PKG  never  appears  in  the  target  software,  and  POINTINGJNFO.OUT  is 
used  by  PROCESSJMSG  to  process  a  message  that  is  not  a  data  structure  load. 


2.8  Miscellaneous  Packages 

Units:  EEPROMJDATA,  ASM.UTILITY,  and  MEMORYJdANAGER 

All  three  Ada  packages  have  package  bodies  written  in  1750A  assembly  code.  Portions 
of  our  target  software  do  in  fact  call  procedures  or  functions  that  appear  in  these  packages, 
but  the  packages  wiU  not  be  translated  by  the  SDVS  Ada  translator.  When  required,  these 
procedure/function  calls  wiU  be  encapsulated  by  a  form  of  offline  characterization. 


8 


3  Possible  SDVS  Enhancements 


There  are  many  Ada  constructs  in  the  target  software  that  are  not  currently  “compilable” 
by  the  SDVS  Ada  translator.  (For  brevity  we  will  henceforth  refer  to  these  as  targeted 
constructs).  Of  these,  the  most  intractable  are  tasking  and  Ada  features  that  pertain  to  it, 
eg.,  delay  statements  and  the  priority  pragma.  Below,  we  hst  each  targeted  construct  and 
note  our  proposed  solution  to  its  presence  in  the  target  software. 


(i)  LONGJFLOAT  and  LONGJNTEGER  types 

These  types  are  not  part  of  standard  Ada  and  are  compiler  dependent.  We  wih  declare 
LONGJFLOAT  (LONGJNTEGER)  to  be  of  type  FLOAT  (INTEGER). 

(ii)  WRITESTRING  and  WRITELN 

These  are  not  in  the  Language  Reference  Manual  [5]  and  appear  in  the  Ada  code  only 
temporarily  (for  testing  purposes).  We  will  delete  them  from  the  target  software. 

(iii)  With  clause 

Currently,  SDVS  allows  this  clause  only  for  the  standard  INTEGERJO  and  TEXT  JO 
packages.  Furthermore,  the  only  Ada  unit  that  may  be  translated  into  the  state  delta 
language  by  the  use  of  adatr  in  SDVS  is  a  main  Ada  procedure.  We  have  already 
started  work  on  the  adatr  implementation,  which  will  involve  the  addition  of  the 
capability  in  SDVS  to  adatr  packages. 

(iv)  Integer  subtypes 

Although  there  is  only  one  instance  of  an  integer  subtype  definition  in  the  target 
software,  we  think  that  integer  subtype  definitions  are  so  prevalent  in  Ada  programs 
in  general  that  it  behooves  us  to  implement  them. 

(v)  Integer  definition  derived  types 

These  type  definitions  appear  in  several  important  parts  of  the  target  software  (WORD 
and  BYTE  are  defined  in  this  manner).  We  wiU  implement  integer  derived  type  defi¬ 
nitions. 

(vi)  Type  conversions 

We  will  implement  them. 

(vii)  Array  initialization  using  (others  =>) 

We  win  implement  it. 

(viii)  Two-dimensional  arrays 

SDVS  currently  handles  only  one-dimensional  arrays.  At  this  point,  we  intend  to 
“Curry”  the  two-dimensional  arrays,  that  is,  to  rewrite  the  code  in  such  a  way  so  that 
a  two-dimensional  array  is  represented  as  a  one-dimensional  array  of  arrays.  This 
solution  is  simple  enough;  if  time  permits,  we  will  consider  the  implementation  of 
multidimensional  arrays. 
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(ix)  Named  parameters 

We  will  change  instances  of  named  parameter  notation  to  their  positional  parameter 
equivalent  in  the  target  software. 

(x)  Hexadecimal  notation 

There  are  many  instances  of  this  in  the  target  software;  since  they  are  all  easy  to 
convert  to  base  10  notation,  we  will  do  so  (rewrite  the  instances). 

(xi)  UNCHECKED-CONVERSION 

This  generic  function  is  instantiated  many  times  in  the  target  software  and  its  instan¬ 
tiations  are  used  repeatedly  and  in  situations  that  are  compiler  dependent,  e.g.,  to 
convert  from  one  object  to  another  of  smaller  size.  We  are  stiU  undecided  on  its  exact 
implementation.  It  appears  that  we  will  not  handle  aU  situations  uniformly.  Certain 
cases  are  obvious,  but  others  are  not. 

(xii)  Size  representation  attribute 

Here  is  an  important  instance  in  the  code: 

type  WORD  is  range  0..65535;  for  WORD’size  use  16; 

In  fact,  all  instances  in  the  Ada  code  are  precisely  of  this  form:  integer  derived 
types  whose  size  attribute  matches  their  range.  We  propose  to  implement  the  size 
attribute  so  as  to  allow  precisely  these  cases.  It  should  be  noted  that  if  an  object  has 
a  constrained  integer  type  declaration,  then  SDVS  will  ensure  that  any  assignment  to 
that  object  obeys  the  restriction. 

(xiii)  Address  representation  attribute 

This  attribute  is  used  either  to  assign  to  or  store  values  of  an  Ada  object  by  means 
of  Ada  procedures  that  have  1750A  assembly  code  bodies.  For  example,  in  the  proce¬ 
dure  CMDJNJEANDLER,  the  array  of  four  words,  Cmd_Unpacked,  is  assigned  a  value 
by  means  of  the  following  call  to  the  procedure  READ_FIFO  of  the  package  MEM¬ 
ORY-MANAGER  (the  body  of  READ_FIFO  is  in  1750A  assembly): 

MEMORY_MANAGER.READJFIFO(CmdJn_FIFO_Addr,  Cmd-Unpacked’address, 

Cmd-Size); 

In  one  instance,  the  size  attribute  is  used  not  only  to  assign  a  value  to  an  Ada  object, 
but  to  do  a  type  conversion  as  well.  AU  such  instances  in  the  target  software  wiU  be 
replaced  by  simple  Ada  procedures  that  wiU  mimic  the  result  of  caUs  to  the  original 
procedures. 

(xiv)  Pragmas  elaborate,  priority,  pack,  Foreign-Body,  and  Linkage-Name 

Ada  pragmas  are  instructions  to  the  compiler  and  are  generally  not  meant  to  change 
the  semantics  of  an  Ada  program.  The  last  two  pragmas  in  the  above  Ust  are  peculiar 
to  the  Tartan  compiler  and  are  used  primarily  for  the  interfaces  to  the  assembly  code, 
which  is  not  a  part  of  the  target  software  we  wUl  translate  into  SDVS;  we  therefore 
think  that  we  may  safely  delete  these  pragmas  from  the  target  software. 
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The  first  pragma,  elaborate,  may  be  deleted  if  we  compile  the  relevant  units  in  the 
correct  order  in  SDVS.  In  this  case,  any  proof  of  correctness  would  be  a  proof  under 
the  assumption  that  the  packages  are  compiled  in  the  correct  order.  Since  this  is  not 
entirely  satisfactory,  we  will  implement  elaborate  if  time  permits. 

The  second  pragma,  priority,  may  guide  the  way  we  handle  the  tasking  in  the  SDVS 
translation  of  the  code,  but  we  wUl  not  implement  it,  since  we  will  not  implement 
tasking  for  this  project. 

The  third  pragma,  pack,  is  used  for  a  particular  format  in  the  representation  of  data 
in  the  target  software,  but  we  do  not  think  its  use  has  any  import  for  the  part  of 
the  code  we  will  consider.  We  think  its  importance  lies  in  that  part  of  the  Ada  code 
that  interfaces  with  parts  written  in  the  1750A  assembly  language  and  therefore  have 
decided  to  delete  it  from  the  target  software.  The  reader  wiU  note  that  none  of  the 
pragmas,  with  the  possible  exception  of  elaborate,  will  be  directly  implemented  in 
SDVS. 

(x)  Tasks 

As  we  have  already  indicated,  the  most  important  and  extensive  part  of  the  target 
software  we  intend  to  verify,  the  part  of  APP_MSGS  that  builds  and  processes  the  appli¬ 
cation  messages  from  the  buffered  serial-digital  commands,  contains  three  tasks  that 
basically  do  all  of  the  work.  Tasking  is  perhaps  the  most  difficult  of  the  Ada  features 
for  an  operational  verification  system  such  as  SDVS  to  handle  efficiently.  The  reason 
for  this  is  that,  in  SDVS,  the  correctness  of  an  Ada  program  is  proved  by  symbolically 
executing  the  SDVS  translation  of  the  program.  Because  of  this  feature  of  SDVS,  a 
branch  in  a  program  may  necessitate  the  execution  to  completion  of  all  the  branches. 
If  a  program  consists  of  several  tasks  that  are  executed  concurrently,  then  every  step 
in  the  execution  of  the  program  may,  in  effect,  be  a  branch:  the  next  statement  to  be 
executed  may  be  any  of  the  next  statements  in  the  tasks.  These  possibilities  lead  to 
an  exponential  growth  in  the  number  of  possible  program  executions. 

Currently,  our  solution  to  the  tasking  problem  is  to  translate  the  tasks  as  procedures 
and  to  treat  rendezvous  as  procedure  calls.  A  main  procedure  wiU  stipulate  the  order 
of  execution  of  the  tasks  in  question.  In  effect,  we  will  consider  the  correctness  of  only 
one  of  the  myriad  possible  program  executions.  The  layout  of  the  main  procedure 
will  be  influenced,  but  not  solely  determined,  by  the  priority  pragma  and  the  delay 
statement  in  APP_MSGS  as  well  as  by  the  rendezvous  that  must  take  place  to  complete 
a  linear  execution  of  the  construction  and  processing  of  an  application  message. 
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Current  and  Future  Work 


We  axe  now  defining  the  semantics  of  the  with  clause  and  will  proceed  with  its  implementa¬ 
tion  and  with  the  implementation  of  the  other  targeted  constructs  that  we  have  decided  to 
add  to  the  SDVS  Ada  translator.  Also,  we  have  started  to  work  on  the  SDVS  specifications 
of  the  targeted  Ada  software. 

Since  the  implementation  of  the  targeted  constructs  will  require  a  great  deal  of  time  to 
complete,  we  propose,  as  a  first  attempt,  to  rewrite^  the  portions  of  the  code  in  which 
they  appear  and  to  translate  and  execute  the  revised  code  in  the  current  SDVS  12  ver¬ 
sion.  This  endeavor  should  at  least  indicate  problems  that  may  arise  in  the  next  phases  of 
the  verification  project.  For  example,  the  abstract-syntax  Ada  trees  created  by  the  SDVS 
translator  may  be  inordinately  large  for  the  system  to  handle:  over  1,000  lines  of  undocu¬ 
mented  Ada  code  must  be  translated  by  the  SDVS  translator,  and  there  are  scores  of  object 
and  object-type  declarations  in  these  lines  that  may  mire  the  system  during  the  symbolic 
execution. 

The  most  serious  problem  we  will  encounter  is  certain  to  be  the  formulation  of  a  workable 
specification  that  accounts  for  the  many  possibilities  that  may  arise  in  the  execution  of  the 
Ada  software.  These  possiblities  are  a  result  of  the  Ada  tasking  used  in  the  software.  As 
we  pointed  out  in  the  last  section,  SDVS  does  not  currently  handle  Ada  tasking  and  will 
probably  not  do  so  in  the  near  future  given  that  the  verification  of  concurrent  programs 
presents  serious  difficulties. 


*  We  will  restore  the  targeted  constructs  in  the  modified  code  to  their  original  version,  alter  we  implement 
them  in  the  SDVS  Ada  translator.  But  many  of  the  modifications  we  will  make  to  the  original  target  software 
will  remain  in  the  final  version  of  the  program  whose  correctness  we  hope  to  prove  (procedures  for  tasks, 
for  example).  Some  of  these  modifications  will  not  alter  the  functionality  of  the  original  code,  but  others 
will.  In  the  final  analysis,  we  will  not  prove  the  correctness  of  the  original  code.  However,  we  think  that  any 
errors  discovered  in  the  modified  code  will  be  a  result  of  errors  in  the  original  code. 
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